Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/dashboard-api/src/__tests__/billing.controller.test.js`:
- Around line 178-180: Replace the undefined AppError references in the
assertions with the mockAppError used elsewhere: update the two expectations
that call expect.any(AppError) and any direct AppError references (e.g.,
expect(next).toHaveBeenCalledWith(expect.any(AppError)) and
expect(next.mock.calls[0][0].statusCode).../message...) to use mockAppError
instead (e.g., expect.any(mockAppError)), keeping the rest of the checks on next
and next.mock.calls intact so they reference the existing mockAppError symbol.

In `@apps/dashboard-api/src/app.js`:
- Around line 158-162: The 500 fallback handler is leaking internal details by
returning err.message; update the error-response in the Express error middleware
(the handler that receives err, req, res) to remove err.message and return only
a fixed public message (e.g. "Internal Server Error" or the existing "Something
went wrong!") and success:false; keep logging the full error (err.stack)
server-side for diagnostics and, if desired, generate/return a safe errorId or
correlation id instead of the raw exception message.

In `@apps/dashboard-api/src/controllers/admin.metrics.controller.js`:
- Around line 142-143: The early-return when cohortSize === 0 returns an
ApiResponse missing d1Pct, d7Pct, and d30Pct; keep the response shape identical
to the non-empty path by including d1Pct: 0, d7Pct: 0, and d30Pct: 0 alongside
month, cohortSize: 0, d1, d7, and d30 in the ApiResponse sent from that branch
(the code constructing the ApiResponse at the cohortSize check).
- Around line 115-116: The current month validation in the controller (the if
that checks month and uses /^\d{4}-\d{2}$/) allows invalid months like 00 or 13;
update that check to reject months outside 01–12 by using a stricter pattern
(e.g. /^\d{4}-(0[1-9]|1[0-2])$/) or parse the captured month and assert 1 <=
month <= 12 before returning new AppError(400, ...). Locate the validation
around the month variable in admin.metrics.controller.js and replace the
regex/condition so invalid month values trigger the AppError.

In `@apps/dashboard-api/src/controllers/auth.controller.js`:
- Around line 591-609: The refreshToken controller currently maps all exceptions
to a 403 "Invalid or expired refresh token"; change the error handling so only
JWT verification errors are converted to an AppError(403) and all other errors
are forwarded to the global handler with next(err). Specifically, in
module.exports.refreshToken around jwt.verify and Developer.findById, detect jwt
errors (e.g. err.name === 'TokenExpiredError' or 'JsonWebTokenError') and call
next(new AppError(403, "Invalid or expired refresh token")), but for any other
error (DB lookup, persistence, unexpected exceptions) call next(err) so they
surface as 5xx; keep references to jwt.verify, Developer.findById,
sendTokenResponse, AppError, and next when implementing this conditional catch
behavior.

In `@apps/dashboard-api/src/controllers/project.controller.js`:
- Around line 2459-2463: The code currently treats 'owner-write-only' as an
allowed RLS mode (see validMode and allowedModes) and returns an error only for
unknown values; instead normalize legacy 'owner-write-only' to 'public-read'
before validation and persistence: when computing validMode (from mode or
collection?.rls?.mode), if the value equals 'owner-write-only' set it to
'public-read', then validate against allowedModes = new
Set(['public-read','private']) and proceed; update the same normalization in the
other block handling RLS (the later code that uses validMode/allowedModes) so
legacy inputs are converted rather than stored.
- Around line 411-416: The file contains unresolved Git conflict markers
(<<<<<<<, =======, >>>>>>>) across several handlers (getSingleProject,
createCollection, getData, toggleAuth, updateAuthProviders, updateCollectionRls
and others) which breaks parsing; open project.controller.js, remove all
conflict markers and decide the correct behavior for each conflicted block
(e.g., prefer centralized error handling via next(new AppError(...)) OR direct
res.status(...).json(...) consistently), reconcile both sides accordingly in
each function (getSingleProject, createCollection, getData, toggleAuth,
updateAuthProviders, updateCollectionRls), keep only one implementation per
block, ensure imports/usage for AppError or res are consistent, run lint/tests
to confirm parsing and CI pass.

In `@apps/dashboard-api/src/controllers/release.controller.js`:
- Around line 71-72: Both getAllReleases and createRelease currently return raw
payloads (an array and { message, count }) instead of the standardized {
success, data, message } shape; update the handlers (e.g., the function using
Release.find() and the createRelease handler around lines noting create logic)
to always respond with res.json({ success: true, data: <payload>, message: "" })
and on failures use the AppError class (not raw throw or exposing Mongo/Mongoose
errors) to forward errors; ensure data contains the actual resource(s) (e.g.,
data: { releases } or data: { release, count }) so callers receive the
consistent schema.

In `@apps/public-api/src/__tests__/userAuth.email.test.js`:
- Around line 254-259: Update the test's success assertion to match the
standardized ApiResponse shape: instead of asserting top-level token and userId,
assert that res.json was called with an object containing success: true and data
that contains token: 'signed_access_token' and userId: 'user_123' (use
expect.objectContaining for both the outer object and the nested data). Locate
the assertion using res.json in this test and align it with the ApiResponse mock
defined earlier in the file.
- Line 109: The test is failing because the controller module has unresolved
merge conflict markers (e.g., <<<<<<<, =======, >>>>>>>) in the
userAuth.controller source; open the controller module, remove the conflict
markers and reconcile the conflicting blocks so the file is valid JavaScript,
ensure the exported symbols (module.exports or named exports used by tests) like
the userAuth controller functions remain correct and consistent after resolving,
save and run the tests to confirm the SyntaxError is gone.

In `@apps/public-api/src/controllers/userAuth.controller.js`:
- Line 1: This file contains unresolved Git merge-conflict markers (<<<<<<<,
=======, >>>>>>>) that break parsing; open the userAuth.controller.js source,
find all conflict regions beginning with "<<<<<<<" and ending with ">>>>>>>" and
choose the correct side (or manually merge both sides) for each conflict across
the occurrences noted (including the other ranges around lines ~1818 and ~3538),
remove the conflict markers, ensure the resulting exports/functions (e.g., any
controller functions or exported handlers in this file) are syntactically valid,
run a quick lint/build to confirm parsing succeeds, and commit the cleaned file.
- Around line 2679-2708: The exchangeSocialRefreshToken handler currently does
separate redis.get and redis.del calls which allow race conditions; update the
logic in exchangeSocialRefreshToken to perform an atomic read-and-delete using
Redis GETDEL (or the client's equivalent) when fetching
getSocialRefreshExchangeKey(rtCode) so the stored payload is retrieved and
removed in one operation, then validate parsedExchange.token and
parsedExchange.refreshToken and proceed as before; ensure you still handle JSON
parse errors and return the same AppError responses.

In `@docker-compose.yml`:
- Around line 8-9: The docker-compose.yml currently publishes datastore ports
(ports: '27017:27017' and similarly '6379:6379') to the host while NODE_ENV:
production is set; remove or restrict these host-facing port mappings for the
Mongo/Redis services: either delete the ports entries so they remain internal to
the Compose network, or change them to bind to localhost (e.g.,
127.0.0.1:27017:27017 and 127.0.0.1:6379:6379), and if host access is needed for
local debugging move the host-published mappings into a dev-only override file
(docker-compose.override.yml) instead; update the mongo/redis service blocks
that contain the ports keys and the specific strings '27017:27017' and
'6379:6379'.

In `@packages/common/src/middleware/checkAuthEnabled.js`:
- Around line 17-21: The middleware currently checks usersCollection.model
entries with strict checks (f.type === 'String' and f.required) which rejects
valid schemas that use lowercase 'string' or truthy numeric/string required
flags; update the check in checkAuthEnabled.js to normalize each field like the
dashboard's project.controller.validateUsersSchema() (treat type
case-insensitively, e.g., 'string' or 'String' as String, and treat required as
truthy for '1', 1, 'true', true, etc.) before testing for email and password
presence; specifically normalize entries from usersCollection.model, then locate
the email and password fields using the normalized.type === 'String' and
normalized.required truthiness and return the same AppError only if either
normalized field is missing.

In `@packages/common/src/middleware/loadProjectForAdmin.js`:
- Around line 7-18: In the loadProjectForAdmin middleware, validate projectId
(use mongoose.Types.ObjectId.isValid or equivalent) before calling
Project.findOne and return next(new AppError(400, "Invalid project ID")) for an
invalid id; then keep the existing owner-restricted query (Project.findOne({_id:
projectId, owner: req.user._id})) and assignment to req.project. In the catch
block, stop echoing err.message to clients—call next(new AppError(500, "Internal
Server Error")) and log the original err internally (e.g., console.error or
req.logger) instead of returning err.message.

In `@packages/common/src/middleware/standardizeApiResponse.js`:
- Around line 70-78: The current fallback replaces a parsed string message from
toErrorMessage(body) with raw body.error objects/arrays; update the conditional
logic in the standardizeApiResponse middleware so you only assign
errorTitle/errorMessage from body.error when body.error is a string (i.e., keep
the existing checks `if (body.error && typeof body.error === 'string')` and do
not set errorMessage from body.error when it is an object/array), and ensure the
previously computed toErrorMessage(body) result remains the message when
body.error is non-string; reference the variables and helpers errorTitle,
errorMessage, body.error and the toErrorMessage function to locate and change
the fallback logic.

---

Outside diff comments:
In `@apps/dashboard-api/src/controllers/analytics.controller.js`:
- Around line 42-46: The follow-up Project.find used to build projectIds uses a
different owner variable/type than earlier (user_id vs userId) causing
mismatched filters and understating totalRequests/totalWebhooks/totalUsers;
update the Project.find call that produces projects (and any subsequent queries
that use its results) to use the same owner filter/type as used when computing
totalProjects (e.g., use owner: userId or convert userId to an ObjectId via
mongoose.Types.ObjectId(userId)) so Project.find, projects.map, totalRequests,
totalWebhooks, and totalUsers all filter by the identical owner value/type.

In `@apps/dashboard-api/src/controllers/auth.controller.js`:
- Around line 295-315: The register handler and other auth responses (including
sendTokenResponse-based flows and getMe) return legacy bodies and must be
changed to the standardized envelope { success: boolean, data: {...}, message:
"" }; update register (function register) to return res.status(201).json({
success: true, data: { userId: newDev._id } or { user: sanitizedUser }, message:
"Registered successfully" }) instead of { message: ... }, and update failure
responses to use { success: false, data: {}, message: "..." } where appropriate;
refactor the sendTokenResponse helper to emit the same envelope
(success/data/message) and adjust all callers (the sendTokenResponse-based
paths) to stop returning { success: true, user: ... } so getMe and other
handlers return { success, data, message } consistently; ensure any Zod/AppError
branches also respond via next(...) or the envelope format so all auth endpoints
conform to the single contract.

In `@apps/dashboard-api/src/controllers/billing.controller.js`:
- Around line 183-195: The webhook signature comparison can throw if Buffer
lengths differ; before calling crypto.timingSafeEqual, explicitly check that
Buffer.byteLength(signature) (or Buffer.from(signature).length) equals
Buffer.byteLength(expectedSignature) (or Buffer.from(expectedSignature).length)
and if not, return next(new AppError(401, 'Invalid webhook signature.')); update
the block around the variables signature, expectedSignature and the
crypto.timingSafeEqual call to perform this length check and only call
timingSafeEqual when lengths match.

In `@apps/dashboard-api/src/controllers/project.controller.js`:
- Around line 304-305: The controller returns bare objects/arrays and inline
error payloads; update all handlers in project.controller.js to use the
standardized response envelope { success: boolean, data: object, message: string
} (for example replace res.status(201).json(projectObj) with
res.status(201).json({ success: true, data: projectObj, message: 'Project
created' })), and convert all catch blocks to propagate errors via the AppError
class (or call next(new AppError(...))) instead of sending raw MongoDB/error
objects or throwing raw errors; search for occurrences of projectObj, any direct
res.json/res.status(...).json({...}) that return arrays/objects or { error: ...
} / { success: ... } and normalize them to the envelope and use AppError for
error cases across the listed ranges.

In `@apps/dashboard-api/src/controllers/userAuth.controller.js`:
- Around line 345-370: The controller is calling getAuthCollection in
resetPasswordUser and updateProfile but that symbol is not defined or imported;
add a proper import or require for getAuthCollection (the same function used
elsewhere to obtain the auth collection) at the top of this file and ensure the
imported name matches the one used in resetPasswordUser and updateProfile, or
alternatively define a local wrapper that calls the shared getAuthCollection
implementation so the calls to getAuthCollection(project) resolve without
throwing ReferenceError.
- Around line 64-116: The signup handler (module.exports.signup) currently sends
a bare JSON body (token, message, userId); update its final res.status(201).json
call to use the standard response envelope { success: true, data: { token,
userId }, message: "User registered successfully. Please verify your email." }
and do the same for all other handlers in this controller (e.g., the other
exported auth methods referenced in the review) by replacing any raw or
inconsistent responses (bare tokens, raw user objects, { sessions }, { message
}) with the { success, data, message } shape so callers can rely on a consistent
contract.

In `@apps/public-api/src/__tests__/userAuth.refresh.test.js`:
- Around line 221-248: The test currently asserts direct res.status/res.json
behavior for soft-deleted users but the refreshed controller.refreshToken now
forwards errors via next(AppError); update the test to call
controller.refreshToken(req, res, next) and assert next was called with an
AppError (check instance/type and that it contains status 403 and a message
containing "deletion"), assert res.status/res.json were not used, and still
assert res.clearCookie was called with 'refreshToken'; keep existing mocks
(getRefreshSession, Project.__chain.lean, mockModel.findOne) and only change the
assertions and invocation to validate the next(AppError) error path.

In `@apps/public-api/src/__tests__/userAuth.social.test.js`:
- Around line 462-535: Remove the merge conflict markers and restore the atomic
GETDEL branch: in the tests for controller.exchangeSocialRefreshToken (file
userAuth.social.test.js) delete the conflict blocks and keep the assertions that
reference redis.getdel (not redis.get + redis.del), ensure calls to
exchangeSocialRefreshToken still pass next where appropriate, and retain the
expectations that check res.status/res.json responses for success and error
cases (and the test that uses redis.getdel.mockResolvedValueOnce(...) for
payload mismatch). Also remove the alternative redis.get/redis.del assertions
and the next/AppError-style expectations introduced by the other branch so the
tests reflect the atomic GETDEL behavior.

In `@apps/public-api/src/controllers/data.controller.js`:
- Around line 218-230: Remove the Git conflict markers and the upstream branch
block and keep the stashed change that uses AppError: replace the entire
conflicted block (the lines with <<<<<<<, =======, and >>>>>>> plus the
res.status(...) branch) with the single statement that calls next(new
AppError(404, "Collection not found")); ensure you reference the existing
collectionConfig check and the next/AppError usage so the endpoint follows the
project's error-handling convention and no raw res.status().json() remains.

---

Nitpick comments:
In `@apps/dashboard-api/src/controllers/webhook.controller.js`:
- Around line 59-70: Replace the ad-hoc success responses in
webhook.controller.js with the standardized ApiResponse pattern: for each place
that currently calls res.json(...) or res.status(...).json(...), construct an
ApiResponse({ success: true, message: "<same message>", data: { ... } }) and
call .send(res, <statusCode>) instead; specifically update the response around
the webhook object (the block returning _id, projectId, name, url, events:
Object.fromEntries(webhook.events || new Map()), enabled, createdAt) and the
other success sites referenced (around lines 110, 145, 211, 261, 307, 415) so
they all use ApiResponse(...).send(res, status) and preserve the same data
payloads and HTTP status codes. Ensure you import/require ApiResponse if not
already present.

In `@apps/public-api/src/__tests__/aggregation.test.js`:
- Around line 6-7: The ApiResponse mock's send method should match the real
helper by accepting an optional status code defaulting to 200; update the
ApiResponse class in the test so send(res, code = 200) uses the provided code or
defaults to 200 and returns res.status(code).json(...), ensuring compatibility
with aggregateData which calls send(res, 200) and preventing future signature
mismatches.

In `@apps/public-api/src/__tests__/userAuth.email.test.js`:
- Around line 312-314: Update the success-case assertions to validate the
standardized response shape { success, data, message } instead of only checking
top-level message; for each test that currently calls
expect(res.json).toHaveBeenCalledWith(expect.objectContaining({ message:
expect.any(String) })) (and the other weak checks at the mentioned locations),
assert expect(res.json).toHaveBeenCalledWith(expect.objectContaining({ success:
true, data: expect.anything(), message: expect.any(String) })) or adjust data to
expect.any(Object) / null as appropriate for that endpoint; locate and update
the assertions around res.json and any expect.objectContaining usages in the
tests named in userAuth.email.test.js to ensure uniform response format
validation.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@apps/public-api/src/__tests__/userAuth.social.test.js`:
- Around line 449-473: The controller exchangeSocialRefreshToken currently does
separate redis.get and redis.del calls causing a race; change
controller.exchangeSocialRefreshToken to perform an atomic GETDEL (use your
Redis client’s getDel/GETDEL command) against the same key
'project:social-auth:refresh-exchange:{rtCode}', remove the separate del call,
and update the test to mock and expect a single redis.getDel (or getdel) call
returning the JSON payload and assert res.json as before so the exchange is
atomic.

---

Nitpick comments:
In `@apps/public-api/src/__tests__/userAuth.social.test.js`:
- Around line 199-219: Update the two startSocialAuth tests to assert the
redis.set call includes the OAuth state key pattern and TTL: verify redis.set
was called with a key that contains "project:auth:oauth:state:" (the dynamic
state suffix may vary), the stored value (state/token), and the expiration flags
('EX' and 600) in addition to the existing redirect assertions; reference the
controller.startSocialAuth and redis.set invocation so the tests fail if the key
format or TTL changes.